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I. Real Party in Interest 

Tiie real party in interest is Sun IVIicrosystems, Inc., the assignee of record. 
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II. Related Appeals and Interferences 

There are currently no otiier appeals or Interferences, of which Appellants, 
Appellants' legal representative, or the assignee are aware, that will directly affect or be 
directly affected by or have a bearing on the Board's decision in the pending appeal. 
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III. Status of Claims 

In the Final Office Action mailed September 26, 2006, the Examiner rejected 
claims 8-10 under 35 U.S.C. § 102(e) as anticipated by U.S. Patent No. 6,578,015 to 
Haseltine et al. {"Haseltine"); rejected claims 1-7 and 14-20 under 35 U.S.C. § 103(a) as 
being unpatentable over Haseltine in view of PR Newswire, "Sun-Netscape Alliance's 
New Internet Billing Consolidation Application to Help Make Internet Billing a Reality for 
Consumers" {"Newswire^'); and rejected claims 11-13 and 21-29 under 35 U.S.C. 
§1 03(a) as being unpatentable over Haseltine. 

The final rejection of claims 1 -29 is being appealed and a list of the claims on 
appeal is found in the attached Claims Appendix. 

Furthermore, each claim of this patent application is separately patentable, and 
upon issuance of a patent will be entitled to a separate presumption of validity under 
35 U.S.C. § 282. 
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IV. Status of Amendments 

All amendments have been entered. 



6 



Customer No. 22,852 
Application No.: 09/867,645 
Attorney Docket No. 06502.0342-00 

V. Summary of Claimed Subject Matter 

The invention relates generally to a method and system that pemnits real-time 
delivery of customer profile and billing information in an Internet bill presentment and 
payment environment. The method and system minimizes the overhead incurred by the 
requesting Internet bill presentment and payment system and/or a biller by reducing the 
extent of biller-dependent modules, or modules that must be designed specially for each 
biller. 

Independent claim 1 is directed to a bill presentment and payment environment 
with a scheduled time to communicate billing infonnation with a set of billers. See, for 
example, specification at page 6, paragraph 012. The method includes receiving 
customer registration information, including information sufficient to identify the 
customer. See, for example, specification at pages 8-9, paragraph 024. The method 
also includes providing the customer identification information to one of the billers as 
part of a first request indicating enrollment in the bill presentment and payment system. 
See, for example, specification at page 9, paragraph 025. The method further includes 
permitting access by the customer to billing information from the one of the billers at an 
unscheduled time. See, for example, specification at pages 9-10, paragraph 026. 

Dependent claim 2 states that the method also includes transmitting a second 
request to the one of the billers to access billing information, and receiving the billing 
information from the one of the billers. See, for example, specification at pages 9-10, 
paragraphs 025-026. 

Independent claim 6 is directed to a bill presentment and payment environment 
with a scheduled time to communicate billing information with a requesting Internet bill 
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presentment and payment (IBPP) system. See, for example, specification at page 6, 

paragraph 013. The method includes receiving, from a requesting IBPP system, a 

request for information associated with a customer. See, for example, specification at 

page 9, paragraph 025. The method also includes retrieving the requested information. 

See, for example, specification at pages 9-10, paragraph 026. The method further 

includes fonwarding the retrieved information to the requesting IBPP system at an 

unscheduled time. See, for example, specification at pages 9-10, paragraph 026. 

Independent claim 8 is directed to a system for permitting real-time access by a 
customer to billing information in an Internet bill presentment and payment environment. 
See, for example, specification at pages 6-7, paragraph 014. The system includes a 
consolidator module and a biller module, connected to the consolidator module. See, for 
example, specification at pages 10-11, paragraph 028, and Fig. 1, ref. 120 and 130. 
The biller module includes biller-independent submodules for communicating with the 
consolidator module. See, for example, specification at pages 14-15, paragraph 038. 
The biller module also includes biller-dependent modules for retrieving information from 
data stored by the biller. See, for example, specification at pages 14-15, paragraph 
038. The biller module further includes an interface enabling the biller-independent 
submodules to interact with the biller-dependent submodules. See, for example, 
specification a pages 14-15, paragraph 038, and Fig. 3B, ref. 366. 

Dependent claim 9 states that the consolidator module also includes a bill 
presentment and payment module. See, for example, specification a page 12, 
paragraph 032, and Fig. 3A, ref. 312. The consolidator module also includes a client 
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object connected to tlie bill presentment and payment module. See, for example, 

specification a page 12, paragraph 032, and Fig. 3A, ref. 314. 

Dependent claim 1 1 states that the biller module includes a server object, which 
receives a request from the consolidator module, a request handler, connected to the 
server object, and an implementation object which receives the request from the 
request handler. See, for example, specification a page 14, paragraph 036, and Fig. 
3B, ref. 362, 364, 368. 

Dependent claim 12 states that the biller-independent sub-modules include a 
server object, which receives a request from the consolidator module, a request 
handler, connected to the server object, and an implementation object which receives 
the request from the request handler. See, for example, specification a page 14, 
paragraph 036, and Fig. 3B, ref. 362, 364, 368. 

Independent claim 14 is directed to a computer-readable medium including 
instructions for performing a method in a bill presentment and payment environment 
with a scheduled time to communicate billing infonnation with a set of billers. See, for 
example, specification at page 6, paragraph 013. The method includes receiving 
customer registration information, including information sufficient to identify the 
customer. See, for example, specification at pages 8-9, paragraph 024. The method 
also includes providing the customer identification information to one of the billers as 
part of a first request indicating enrollment in the bill presentment and payment system. 
See, for example, specification at page 9, paragraph 025. The method further includes 
permitting access by the customer to billing information from the one of the billers at an 
unscheduled time. See, for example, specification at pages 9-10, paragraph 026. 
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Independent claim 19 is directed to a computer-readable medium including 
instructions for performing a method, when executed by a processor, in a bill 
presentment and payment environment with a scheduled time to communicate billing 
information with a requesting IBPP system. See, for example, specification at page 6, 
paragraph 013. The method includes receiving, from the requesting IBPP system, a 
request for information associated with a customer. See, for example, specification at 
page 9, paragraph 025. The method also includes retrieving the requested information. 
See, for example, specification at pages 9-10, paragraph 026. The method further 
includes forwarding the retrieved information to the requesting IBPP system at an 
unscheduled time. See, for example, specification at pages 9-10, paragraph 026. 

Independent claim 21 is directed to a method of requesting information from a 
biller in a bill presentment and payment environment. See, for example, specification 
at page 6, paragraph 013. The method includes receiving customer registration 
information, including information sufficient to identify the customer. See, for example, 
specification at pages 8-9, paragraph 024. The method also includes providing the 
customer identification information to the biller as part of a request indicating enrollment 
in the bill presentment and payment system. See, for example, specification at page 9, 
paragraph 025. In addition, the request is provided to the biller in accordance with a bill 
data exchange protocol. See, for example, specification at pages 1 1012, paragraphs 
030-031, and pages 13-14, paragraph 035. 

Independent claim 22 is directed to a method of providing billing data to a 
requesting IBPP system, in a bill presentment and payment environment. See, for 
example, specification at pages 6-7, paragraph 014. The method includes receiving a 
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request from the requesting IBPP system. See, for example, specification at page 9, 

paragraph 025. The method also includes retrieving the billing data based on the 

request. See, for example, specification at pages 9-10, paragraph 026. The method 

further includes providing the retrieved data to the requesting IBPP system. See, for 

example, specification at pages 9-10, paragraph 026. In addition, the retrieved data is 

provided to the requesting IBPP system in accordance with a bill data exchange 

protocol. See, for example, specification at pages 1 1012, paragraphs 030-031 , and 

pages 13-14, paragraph 035. 

Independent claim 23 is directed to a real-time bill presentment and payment 
method in a bill presentment and payment environment. See, for example, specification 
at page 6, paragraph 012. The method comprises receiving customer registration 
information, including information sufficient to identify the customer. See, for example, 
specification at pages 8-9, paragraph 024. The method also comprises providing the 
customer identification information to one of the billers as part of a request indicating 
enrollment in the bill presentment and payment system. See, for example, specification 
at page 9, paragraph 025. The method further comprises pemiitting real-time access by 
the customer to billing information from the one of the billers. See, for example, 
specification at pages 9-10, paragraph 026. 

Dependent claim 24 states that the method also includes transmitting a request 
to the one of the billers to access billing information, and receiving the billing infomnation 
from the one of the billers. See, for example, specification at pages 9-10, paragraphs 
025-026. 
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Independent claim 28 is directed to a method for providing billing information to a 

requesting IBPP system in real-time. See, for example, specification at pages 6-7, 

paragraph 014. The method includes receiving, from the requesting IBPP system, a 

request for information associated with a customer. See, for example, specification at 

page 9, paragraph 025. The method also includes retrieving the requested information. 

See, for example, specification at pages 9-10, paragraph 026. The method further 

includes forwarding the retrieved information to the requesting IBPP system in real-time. 

See, for example, specification at pages 9-10, paragraph 026. 
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VI. Grounds of Rejection 

A. Claims 8-10 stand rejected under 35 U.S.C. § 102(e) as anticipated by 
U.S. Patent No. 6,578,015 to Haseltine et al. {"Haseltine"). 

B. Claims 1-7 and 14-20 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Haseltine in view of PR Newswire, "Sun-Netscape Alliance's New 
Intemet Billing Consolidation Application to Help Make Internet Billing a Reality for 
Consumers" {"Newswire"). 

C. Claims 11-13 and 21-29 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Haseltine. 
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VIL Argument 

I. The rejection of claims 8-10 Under § 102(e) as being anticipated by 
Haseltine is improper 

The Examiner's rejection of claims 8-10 under 35 U.S.C. §1 02(e) as being 
anticipated by Haseltine should be reversed. 

To properly anticipate Appellants' claimed invention, the Examiner must 
demonstrate the presence of each and every element of the claim in issue, either 
expressly described or under principles of inherency, in a single prior art reference. 
Furthermore, "[t]he identical invention must be shown in as complete detail as is 
contained in the . . . claim." See MPEP § 2121, quoting Richardson v. Suzuki Motor 
Co. , 868 F.2d 1126, 1236, 9 U.S.P.Q.2d 1913, 1920 (Fed. Cir. 1989). Finally, "[t]he 
elements must be arranged as required by the claim." MPEP § 2131 . In this 
application, the Examiner has not demonstrated that each and every element of the 
claims are taught by Haseltine. 

Claim 8 recites a system including: 
a consolidator module; and 

a biller module, connected to the consolidator module, 
wherein the biller module includes 

biller-independent submodules for communicating with the 

consolidator module : 
biller-dependent modules for retrieving information from data stored 

by the biller : and 

an interface enabling the biller-independent submodules to interact 
with the biller-dependent submodules 



(emphasis added). Haseltine does not disclose at least these elements of Appellants' 
claimed invention. 



14 



Customer No. 22,852 
Application No.: 09/867,645 
Attorney Docket No. 06502.0342-00 

Haseltine discloses a network 300 "including billers, customers, consolidators 

and payment processors" (col. 9, lines 49-50). The Examiner states that thick 

consolidator 350 and thin consolidator 360 correspond to the claimed "consolidator 

module" and billers 310, 320, and 330 correspond to the claimed "biller module" (Final 

Office Action at page 2). The Examiner also asserts, *1hick consolidators maintain 

databases of accounts related to the various billers" and "thin consolidators access 

information maintained at the biller sites" (Final Office Action at page 2). Even 

assuming that this is correct, which Appellants do not concede, the thick consolidators 

and thin consolidators do not constitute the claimed "biller-independent submodules" 

and "biller-dependent submodules" at least because these consolidators are part of the 

consolidator module, not the biller module, as stated by the Examiner and depicted in 

Fig. 3. 

The Examiner also appears to consider thin consolidator access to information 
maintained at the biller sites of Haseltine as a teaching of the claimed "biller-dependent 
modules for retrieving information from data stored by the biller"' (Office Action at 
page 2). This is not correct. 

In Haseltine, the 'Ihin consolidator may maintain a database similar to that shown 
at reference at 400 in FIG 4" (col. 10, lines 46-47). However, because the thin 
consolidator *1ypically carr(ies) only bill summaries," it "refer(s) the customer to the 
biller's own Web site for further detailed bills and/or further customer service, such as to 
discuss a disputed bill" (col. 2, lines 39-42). In "the case wherein the thin consolidator 
also maintains bill detail tables within its database, detailed bill data may also be 
available" (col. 10, line 66 to col. 11, line 1). 
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Thus, when the bill data requested by the customers is available within its 
database, the thin consolidator may retrieve the data from its own database and present 
it to the customers so that the customers can "view and/or pay" their "bills for one or 
more billers having contracted with the thin consolidator" (col. 10, lines 61-62). 
However, when the bill data requested by the customers is not available, the thin 
consolidator "refer(s) the customer to the biller's own Web site for further detailed bills." 
(col. 2, lines 39-41). To successfully refer the customer to the biller's own Web site, 
"the thin consolidator may also maintain a customer-accessible link to" the biller's Web 
site (col. 1 1 , lines 2-3). The customers then directly connect to the biller' Web site and 
obtain "detailed bill information independentiv of the thin consolidator" (col. 11, lines 
11-15) (emphasis added). Nothing in Haseltine discloses a thin consolidator "for 
retrieving information from data stored by the biller," as recited in claim 8. 

Claim 1 recites a "biller module [that] includes . . . biller-dependent modules for 
retrieving information from data stored by the biller." Thin consolidator 360 is not 
located within billers 310, 320, and 330 (See Fig. 3). Therefore, Haseltine does not 
teach or suggest "biller-dependent submodules for retrieving information from data 
stored by the biller" at least because any retrieval in Haseltine occurs by consolidators 
that are separate from the biller module. Therefore, Haseltine does not teach or 
suggest " biller-dependent modules for retrieving information from data stored by the 
biller; and an interface enabling the biller-independent submodules to interact with the 
biller-dependent submodules," as further recited in claim 8. 

Claim 9 depends from claim 8. As previously stated, Haseltine does not support 
the rejection of claim 8. Accordingly Haseltine also does not support the rejection of 
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claim 9 for at least the same reasons set forth above in connection with claim 8. 

Further, Haseltine does not disclose "a client object, connected to the bill presentment 

and payment module," as recited in claim 9. 

The Examiner states, "Haseltine teaches objects in that a customer logs onto a 
web page to view and/or pay his or her bills" (Final Office Action at page 14). The 
Examiner cites col. 5, lines 15-23 and col. 10, lines 25-33 to teach the claimed "client 
object." This is not correct. 

Col. 5, lines 15-23 discloses bill format data 404 that may include 
HTML-formatted data "configured to mimic the 1ook-and-feer of the biller's traditional 
paper bills." Billers fonts, background color scheme, graphic designs, and/or layout may 
be reproduced. Col. 10, lines 25-33 discloses bill summary data and bill detail data may 
be available from the bill summary tables 432 and bill detail tables 434 when 'Ihe 
customer 370 logs onto the Web site of the thick consolidator." Appellants find no 
teaching or suggestion in these passages of the claimed "client object." 

On the contrary, as stated in the Reply filed July 6, 2006, Haseltine discloses an 
embodiment of the invention "implemented as a database" (col. 4, lines 41-42). 
Haseltine further indicates that the invention is implemented as a relational database. 
For example, Haseltine specifically mentions that the data can be loaded into "a 
database (such as an Oracle Corp. database, for example), via mechanisms such as 
Oracle's SQL*Loader utility or other Relational Database Management System 
(RDBMS) utilities" (col. 5, lines 33-36). Haseltine further discloses that 'Ihe partitioning 
process may be carried out according to the parameters set out, for example, in chapter 
8 of Oracled Server Concepts, release 8.0© 1997 Oracle Corporation" (col. 5, line 67 - 
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col. 6, line 2). However, an Oracle database is a relational database, and Haseltine 

does not disclose embodiments implemented as other type of databases. Therefore, 

Haseltine does not teach or suggest the claimed "a client object, connected to the bill 

presentment and payment module," as recited in claim 9. 

For at least this additional reason, the cited art does not support the rejection of 

claim 9. Claim 10 depends from claim 9. As explained, Haseltine does not support the 

rejection of claim 9. Accordingly Haseltine also does not support the rejection of claim 

10 for at least the same reasons set forth above in connection with claims 8 and 9. 

Accordingly, Haseltine cannot anticipate claims 8-10. Therefore, Appellants respectfully 

request that the Board reverse the rejection of claims 8-10 under 35 U.S.C. § 102(e). 

II. The rejection of claims 1-7 and 14*20 under § 103(a) as being 
unpatentable over Haseltine in view of Newswire is improper 

The Examiner's rejection of claims 1-7 and 14-20 under 35 U.S.C. § 103(a) as 

being unpatentable over Haseltine in view of Newswire should be reversed. 

To establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or to combine reference 
teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach 
or suggest all the claim limitations. The teaching or suggestion to make 
the claimed combination and the reasonable expectation of success must 
both be found in the prior art, and not based on applicant's disclosure. In 
re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). M.P.E.P. 
§ 2142, 8th Ed., Rev. 2 (May 2004), p. 2100-128. 

A prima facie case of obviousness has not been established because, among 
other things, neither Haseltine nor Newswire, taken alone or in combination, teach or 
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suggest each and every element recited by Appellants' claims. A prima facie case of 

obviousness has, therefore, not been established. 

Claim 1 recites a method including: 

providing the customer identification information to one of the billers 
as part of a first request indicating enrollment in the bill presentment and 
payment system; and 

(emphasis added). Haseltine discloses two ways that the customers may register 

themselves to the bill presentment and payment database. "Customers wanting to view 

and pay bills may register themselves by accessing an HTML registration page" (col. 8, 

lines 65-66). "Alternatively, billers may supply the necessary customer information and 

enroll or register customers in a batch mode by loading the customer data into an 

interface provided in the staging area 420 over"' http or ftp (col. 8, line 67 - col. 9, line 5). 

In both enrollment methods disclosed in Haseltine, the enrollment data collected or 

transmitted by the billers in the process is stored within the database. As a result, the 

customers log onto the system where the database is maintained. For example, in the 

case wherein the thick consolidator maintains the database, a "customer may log onto 

an Internet Web site maintained by the thick consolidator" (col. 10, lines 15-17). 

Because the customers log onto the system where the enrollment data is stored, the 

customer does not provide identification "information to one of the billers as part of a 

first request indicating enrollment." 

The Examiner cites col. 9, lines 23-27 of Haseltine and states "that customers 

enroll in a system and that each customer has a unique user account including a 

plurality of biller accounts, one such biller account for each biller from whom the 

customer receives bills" (Final Office Action at page 14). Even though customer 
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accounts may correspond to the appropriate billers, there is no teaching in Haseltine of 

"providing the customer identification information to one of the billers as part of a first 

request." On the contrary, any customer information in Haseltine is provided at an 

HTML registration page or staging area 420 as previously stated. The HTML 

registration page and staging area 420 are not present within the billers. 

The Examiner also cites col. 1 1 , lines 5-14 of Haseltine and states, "when further 
information is needed the consolidator uses a customer specific URL to the biller's 
website" (Final Office Action at page 14). Haseltine discloses, *1he thin consolidator 360 
may also maintain a customer-accessible link to the billers 310, 320 to provide the 
customer 380 with detail bill data, customer service or other customer services" 
(emphasis added) (col. 1 1 , lines 2-5). Col. 1 1 , lines 5-14 of Haseltine provides an 
example of thin consolidator access to provide a customer with "detailed bill 
information." Information is retrieved and provided to the customer. No infomnation is 
provided to the biller . 

Even assuming that URL connecting the customer and the biller facilitates 
sending identifying information from the consolidator to the biller, which Appellants do 
not concede, the URL provides the customer "with detailed bill information" (col. 1 1 , 
lines 13-14). However, this detailed bill information only exists because the customer 
has previously enrolled. Therefore, even assuming that the act of sending information 
from the consolidator to the biller constitutes a request, which Appellants do not 
concede, Haseltine does not teach or suggest "providing the customer identification 
information to one of the billers as part of a first request indicating enrollment in the bill 
presentment and pavment svstem ." as recited in claim 1 . 
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The Examiner correctly notes tliat Haseltine does not teach *1he step wherein the 

customer is permitted access to the billing information at an unscheduled time" (Final 

Office Action at page 4). However, the Examiner relies on Newswire to teach this 

limitation. 

Even if the Examiner's reliance is appropriate, Newswire does not cure the 
deficiencies of Haseltine. Newswire discloses an internet bill presentment and payment 
solution. However, Newswire does not teach or suggest "providing the customer 
identification information to one of the billers as part of a first request indicating 
enrollment in the bill presentment and payment system," as recited in claim 1. 
Accordingly, Haseltine and Newswire fail to establish a prima facie case of obviousness 
with respect to claim 1 , at least because the references fail to teach each and every 
element of the claim. 

Claims 2-5 depend from claim 1 . As explained, the cited art does not support the 
rejection of claim 1 under 35 U.S.C. § 103(a). As such, the cited art does not support 
the rejection of claims 2-5 for at least the same reasons set forth in connection with the 
response to the rejection of claim 1 , Further, Haseltine in view of Newswire does not 
disclose or suggest the recitations of these dependent claims. For example, Haseltine 
or Newswire does not teach or suggest "transmitting a second request to the one of the 
billers to access billing information," as recited in claim 2. 

The Examiner appears to assert that a URL linking a customer to a first biller 
constitutes a **first request," and a URL linking a customer to a second biller constitutes 
a "second request" (Final Office Action at page 14), The Examiner position is incorrect 
for two reasons. 
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First, a customer accessible link in a form of URL merely provides the location 
information of the billers' Web site. Thus, when customers click the customer 
accessible link, the customers' browsers send HTTP requests directly to the billers' Web 
site using the location information from the link without any further participation or 
processing from the consolidator. Accordingly, maintaining the customer accessible link 
cannot constitute ^transmitting a second request to the one of the billers to access 
billing information," as recited in claim 2. 

Second, even assuming that the URL of Haseltine constitutes a request, which 
Appellants do not concede, there is only one URL, or request, for each biller, as stated 
by the Examiner (Final Office Action at page 14). Therefore, any "second request" in 
Haseltine would be a request for a different biller. In contrast, the "second request" in 
claim 2 is a "second request" to access billing information from the same biller that 
received the "first request." Therefore, because any second request in Haseltine links 
the customer to a second biller as stated by the Examiner, Haseltine does not teach or 
suggest "transmitting a second request to the one of the billers to access billing 
information," as recited in claim 2. For at least these additional reasons, the cited art 
does not support the rejection of claims 2-5 under 35 U.S.C. § 103(a). 

Independent claim 14, though of different scope from claim 1, recites limitations 
similar to those set forth above with respect to claim 1 . Claim 14 is therefore allowable 
for at least the reasons presented above. Claims 15-18 are also allowable at least due 
to their dependence from claim 14. 
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Claim 6 recites a method including: 

receiving, from a requesting IBPP system , a request for information 
associated with a customer; 

fonvardinq the retrieved information to the requesting IBPP system 
at an unscheduled time . 

(emphasis added). The Examiner states, *1he steps of logging on represents an implied 

request for information" is taught by Haseltine at column 10, lines 44-52 (Final Office 

Action at page 5). In Haseltine, the customers, not the IBPP systems, log onto the 

system. Therefore, even if the logging onto the system represents an implied request, 

which Appellants do not concede, the request is not from a IBPP system. Accordingly, 

Haseltine does not teach "receiving, from a IBPP system, a request for infomiation 

associated with a customer," as recited in claim 6. 

The Examiner admits that Haseltine does not teach "wherein the retrieved 
information is fonA/arded at an unscheduled time" (Final Office Action at page 6). The 
Examiner, however, alleges,"[i]t would have been obvious to anyone skilled in the 
ordinary art at the time of invention to include the teachings of Newswireto the 
disclosure of Haseltine so that a customer can access their account information anytime 
they choose" (Final Office Action at page 6). Appellants respectfully disagree. 

Newswire does not teach or suggest **fonA/arding the retrieved information to the 
requesting IBPP system at an unscheduled time," as asserted by the Examiner. 
Newswire discloses that the billers "can reach customers more than just once a month" 
(Page 2, paragraph 5). Instead of mailing a bill to a customer at a preset time (e.g. 
once a month), "the customer can log onto their online banking site to view a summary 
of bills from their service providers" (Page 2, paragraph 5). 
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The online banking site of Newswire receives bills from the service providers 
once the billing period ends. When the bills are received, the banking site can post the 
bills for the customer to view as often as he would like. However, the fact that the bills 
can reach the customer more than once a month (i.e. allowing the customer to view the 
bill many times), does not mean that the online banking site receives the information at 
an unscheduled time. On the contrary, the information is received at the end of the 
billing cycle and can be viewed or paid by the customer at any time. 

In Newswire, bill information is fonA^arded to the online banking site at specific, 
scheduled time (end of the billing cycle), and the customer view and pay the bill at any 
time. Customer viewing and payment occurs independent from information fonwarding 
to the banking site. Therefore, Newswire does not teach or suggest "forwarding the 
retrieved information to the requesting IBPP system at an unscheduled time," as recited 
in claim 6. 

Accordingly, Haseitme and Newswire fail to establish a prima facie case of 
obviousness with respect to claim 6, at least because the references fail to teach each 
and every element of the claim. Claim 7 depends from claim 6 and is thus also 
allowable for at least the same reasons as claim 6. 

Independent claim 19, though of different scope from claim 6, recites limitations 
similar to those set forth above with respect to claim 6. Claim 19 is therefore allowable 
for at least the reasons presented above. Claim 20 is also allowable at least due to its 
dependence from claim 19. Therefore, Appellants respectfully request that the Board 
reverse the rejection of claims 1-7 and 14-20 under 35 U.S.C. § 103(a). 
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III. The rejection of claims 11-13 and 21-29 under § 103(a) as being 
unpatentable over Haseltine is improper 

The Examiner's rejection of claims 11-13 and 21-29 under 35 U.S.C. § 103(a) as 
being unpatentable over Haseltine should be reversed. The prior art cited by the 
Examiner, Haseltine, does not teach or suggest each and every element of claims 
11-13. A phma facie case of obviousness has, therefore, not been established. 

Regarding the rejection of claim 1 1 , the Examiner incorrectly asserts that 
Haseltine discloses "an example wherein the consolidator module request[s] information 
from the biller, the biller handles this request and further implements the request 
(Column 1 1 , line 5-14). In this case, the consolidator is requesting account infomnation 
for a particular customer that is maintained at the biller site" (Final Office Action at 
page 7). Appellants respectfully disagree with the Examiner's interpretation of the cited 
art. 

The consolidators of Haseltine do not make requests to the billers in response to 
customers requests. Col 1 1 , line 5-14 discloses, *1hin consolidator 360 may maintain a 
customer-accessible link to the billers." However, as explained earlier, when the 
customers use the customer accessible link in the form of a URL, it is the customers 
that make direct requests to the billers. The Examiner states, "it is still the consolidator 
that does the linking. . . The communication, and therefore the request, is not made 
directly from customer to biller" (Final Office Action at page 15). This is not correct. 

Haseltine explicitly states, "the thin consolidator may include a URL linking the 
customer 380 directiv into a Web page containing the customer's 380 (detailed) billing 
data, thereby conveniently providing the customer 380 with detailed bill information 
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independently of the thin consolidator 360" (col. 1 1 , lines 9-14) (emphasis added). 

Therefore, the Examiner is incorrect in asserting that Haseltine discloses an example 

wherein the consolidator module requests information from the biller and that the 

consolidator is requesting account information for a particular customer that is 

maintained at the biller site. 

Further, in rejecting claims 1 1 and 12, the Examiner correctly admits that 
Haseltine does not explicitly disclose "a server object, which receives a request from the 
consolidator module," "a request handler, connected to the server object," and "an 
implementation object which receives the request from the request handler" (Final 
Office Action at page 7). However, the Examiner incorrectly asserts that these system 
components would have been obvious in order to "execute the disclosed example, 
yielding a tangible result" (Final Office Action at page 7). As previously stated, 
Haseltine discloses a relational database, which does not implement objects. 

Accordingly, nothing in Hase/f/ne "suggests the desirability" of use of objects in 
the implementation to yield a tangible result, as asserted. Thus, there is no reason why 
one skilled in the art would look to use "a server object, which connected to the server 
object," "a request handler, connected to the server object," and "an implementation 
object which receives the request from the request handler"' as asserted by the 
Examiner. Therefore, the conclusion in the Office Action was not reached based on 
facts gleaned from the cited reference. Instead, teachings of the present application 
were improperly used in hindsight to reconstruct the prior art. For at least these 
additional reasons, the Examiner has not established a prima facie case of obviousness 
with respect to claim 11-13. 
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Since the cited prior art fails to teach each and every element of claims 11-13, no 

prima facie case of obviousness, based on Haseltine, can be established for these 

claims. 

Claim 21 recites a method including: 

providing the customer identification information to the biller as part 
of a request indicating enrollment in the bill presentment and payment 
system , 

(emphasis added). As previously stated, Haseltine discloses two ways that the 
customers may register themselves to the bill presentment and payment database. 
"Customers wanting to view and pay bills may register themselves by accessing an 
HTML registration page" (col. 8, lines 65-66). "Alternatively, billers may supply the 
necessary customer information and enroll or register customers in a batch mode by 
loading the customer data into an interface provided in the staging area 420 over" http 
or ftp (col. 8, line 67 - col. 9, line 5). In both enrollment methods disclosed in Haseltine, 
the enrollment data collected or transmitted by the billers in the process is stored within 
the database. As a result, the customers log onto the system where the database is 
maintained. For example, in the case wherein the thick consolidator maintains the 
database, a "customer may log onto an Internet Web site maintained by the thick 
consolidator" (col. 10, lines 15-17). Because the customers log on the system where 
the enrollment data is stored, the customer does not provide identification information to 
one of the billers as part of a first request indicating enrollment. 

Haseltine discloses, 'Ihe thin consolidator 360 may also maintain a customer- 
accessible link to the billers 310, 320 to provide the customer 380 with detail bill data, 
customer sen/ice or other customer services" (emphasis added) (col. 1 1 , lines 2-5). 



27 



Customer No. 22,852 
Application No.: 09/867,645 
Attorney Docl<et No. 06502.0342-00 

Col. 1 1 , lines 5-14 of Haseltine provide an example of thin consolidator access to 

provide a customer with "detailed bill information." Information is retrieved and provided 

to the customer. No information is provided to the biller . 

The Examiner cites col. 9, lines 23-27 of Haseltine and states "that customers 
enroll in a system and that each customer has a unique user account including a 
plurality of biller accounts, one such biller account for each biller from whom the 
customer receives bills" (Final Office Action at page 14). Even though customer 
accounts may correspond to the appropriate billers, there is no teaching in Haseltine of 
"providing the customer identification infonnation to one of the billers as part of a first 
request." On the contrary, any customer infomiation in Haseltine is provided at an 
HTML registration page or staging area 420 as previously stated. The HTML 
registration page and staging area 420 are not present within the billers. 

The Examiner also cites col. 1 1 , lines 5-14 of Haseltine and states, "when further 
information is needed the consolidator uses a customer specific URL to the biller's 
website" (Final Office Action at page 14). Haseltine discloses, "the thin consolidator 360 
may also maintain a customer-accessible link to the billers 310, 320 to provide the 
customer 380 with detail bill data, customer service or other customer services" 
(emphasis added) (col. 1 1 , lines 2-5). Col. 1 1 , lines 5-14 of Haseltine provides an 
example of thin consolidator access to provide a customer with "detailed bill 
information." Information is retrieved and provided to the customer. No infomiation is 
provided to the biller . 

Even assuming that URL connecting the customer and the biller facilitates 
sending identifying information from the consolidator to the biller, which Appellants do 
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not concede, the URL provides the customer "with detailed bill information" (col. 1 1 , 

lines 13-14). However, this detailed bill information only exists because the customer 

has previously enrolled. Therefore, even assuming that the act of sending information 

from the consolidator to the biller constitutes a request, which Appellants do not 

concede, Haseltine does not teach or suggest "providing the customer identification 

information to the biller as part of a request indicatino enrollment in the bill presentment 

and payment system," as recited in claim 21. The rejection of claim 21 under 

35 U.S.C. § 103(a) based on Haseltine is therefore improper. 

Independent claim 23, though of different scope from claim 21 , recites limitations 
similar to those set forth above with respect to claim 21 . Claim 23 is therefore allowable 
for at least the reasons presented above. Claims 24-27 are also allowable at least due 
to their dependence from claim 23. Moreover, Haseltine does not disclose or suggest 
the elements of claim 24. Claim 24 recites elements similar to those of claim 2. As 
explained in the response to the Examiner's rejection of claim 2, Haseltine does not 
disclose "transmitting a second request to the one of the billers to access billing 
infomnation." Also, Haseltine does not disclose "transmitting a request to the one of the 
billers to access billing information." Therefore, no prima facie case of obviousness, 
based on Haseltine, can be established for these claims. 

Claim 22 recites a method including: 

receiving, from the requesting IBPP system, a request : 
retrieving the billing data based on the request; and 
providing the retrieved data to the requesting IBPP svstem . . . 

(emphasis added). The Examiner cites col 10, lines 26-32 of Haseltine as a teaching of 

the claimed "retrieving" and "providing" (Office Action at pages 9-10). Any IBPP system 
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that may exist in Haseltine includes the Web site where the customer can view and pay 

bills and the thick consolidator 350, at least because the bills cannot be presented and 

paid without Web site interaction. Col. 10, lines 26-32 of Haseltine discloses the 

customer ability to view and pay bills on the Web site. As stated by the Examiner, the 

claimed "request" is implied by logging on (Final Office Action at page 9). However, 

logging on results in bills displayed on the Web site. 

Any "receiving," "retrieving, " and "providing" that may exist in the cited portions 
of Haseltine are located within the IBPP system. Any implied request is received by the 
IBPP system, which also displays the bills for viewing payment. Any "retrieving" and 
"providing" occurs at the Web site. Even assuming that the steps of "receiving," 
"retrieving," and "providing" are present, which Appellants do not concede, they occur 
within the IBPP system. Therefore, Haseltine does not teach or suggest "receiving, 
from the requesting IBPP system, a request" at least because any receiving in the cited 
portions of Haseltine occurs by the IBPP. Moreover, Haseltine does not teach or 
suggest "providing the retrieved data to the requesting IBPP system," as recited in 
claim 22, at least because any providing in the cited portions of Haseltine occurs by the 
IBPP, and the IBPP does not provide data to itself. The rejection of claim 22 under 
35 U.S.C. § 103(a) based on Haseltine is therefore improper. 

Independent claim 28, though of different scope from claim 22, recites limitations 
similar to those set forth above with respect to claim 22. Claim 28 is therefore allowable 
for at least the reasons presented above. Claim 29 is also allowable at least due to its 
dependence from claim 28. Therefore, Appellants respectfully request that the Board 
reverse the rejection of claims 1 1-13 and 21-29 under 35 U.S.C. § 103(a). 
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CONCLUSION 



For at least the reasons given above, pending claims 1-29 are allowable over the 
applied prior art reference. Therefore, Appellants respectfully request the Board to 
reverse the Examiner's rejection of claims 1-29. 

To the extent any extension of time under 37 C.F.R. § 1 .1 36 is required to obtain 
entry of this Appeal Brief, such extension is hereby respectfully requested. If there are 
any fees due under 37 C.F.R. §§ 1 .16 or 1 .17 which are not enclosed herewith, 
including any fees required for an extension of time under 37 C.F.R. § 1 .136, please 
charge such fees to our Deposit Account No. 06-0916. 



Respectfully submitted, 



FINNEGAN, HENDERSON, FARABOW, 
GARRETT & DUNNER, LL.P. 



Dated: April 23, 2007 




Jeffrey A. Berkov 
Reg. No. 36,743 
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VIIL Claims Appendix to Appeal Brief Under Rule 41.37(c)(1)(viii) 

1 . In a bill presentment and payment environment with a scheduled time to 
communicate billing Information with a set of billers, a bill presentment and payment 
method comprising: 

receiving customer registration information, including information sufficient to 
identify the customer; 

providing the customer identification information to one of the billers as part of a 
first request indicating enrollment in the bill presentment and payment system; and 

permitting access by the customer to billing information from the one of the billers 
at an unscheduled time. 

2. The method of claim 1 , wherein permitting access by the customer to billing 
information comprises: 

transmitting a second request to the one of the billers to access billing 
information; and 

receiving the billing information from the one of the billers. 

3. The method of claim 1 , wherein the first request is independent of the biller. 

4. The method of claim 1 , wherein the billing information includes at least one of 
a customer profile or billing data associated with the customer. 
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5. The method of claim 1 , wherein the customer identification information 
includes one or more of name, address, phone number, e-mail address, social security 
number, date of birth, or account number. 

6. In a bill presentment and payment environment with a scheduled time to 
communicate billing information with a requesting Internet bill presentment and payment 
(IBPP) system, a method for providing billing information comprising: 

receiving, from a requesting IBPP system, a request for information associated 
with a customer; 

retrieving the requested information; and 

fonrt^arding the retrieved information to the requesting IBPP system at an 
unscheduled time. 

7. The method of claim 6, wherein the step of forwarding the retrieved 
information comprises the steps of: 

transforming the retrieved information to a format accepted by the requesting 
IBPP system; and 

foHA/arding the transformed information to the requesting IBPP system. 

8. A system for permitting real-time access by a customer to billing information in 
an Internet bill presentment and payment environment, the system comprising: 

a consolidator module; and 

a biller module, connected to the consolidator module, 
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wherein the biller module includes 

biller-independent submodules for communicating with the consolidator 

module; 

biller-dependent modules for retrieving information from data stored by the 

biller; and 

an interface enabling the biller-independent submodules to interact with 
the biller-dependent submodules. 

9. The system of claim 8 wherein the consolidator module includes: 
a bill presentment and payment module; and 

a client object, connected to the bill presentment and payment module. 

10. The system of claim 9, wherein the bill presentment and payment module 
provides an interface for accepting registration and requests from the customer. 

1 1 . The system of claim 8, wherein the biller module includes: 

a server object, which receives a request from the consolidator module; 

a request handler, connected to the server object; and 

an implementation object which receives the request from the request handler. 

12. The system of claim 8, wherein the biller-independent sub-modules include: 
a server object, which receives a request from the consolidator module; 

a request handler, connected to the server object; and 
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an implementation object which receives the request from the request handler. 

13. The system of claim 12, wherein the implementation object is configured to 
implement the interface, based on information included in the request. 

14. A computer-readable medium including instructions for performing a method 
in a bill presentment and payment environment with a scheduled time to communicate 
billing information with a set of billers, when executed by a processor, the bill 
presentment and payment method comprising: 

receiving customer registration information, including information sufficient to 
identify the customer; 

providing the customer identification information to one of the billers as part of a 
first request indicating enrollment in the bill presentment and payment system; and 

permitting access by the customer to billing information from the one of the billers 
at an unscheduled time. 

15. The computer-readable medium of claim 14, wherein the step of permitting 
access by the customer to billing information comprises: 

transmitting a second request to the one of the billers to access billing 
information; and 

receiving the billing information from the one of the billers. 
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16. Tlie computer-readable medium of claim 14, wherein the first request is 
independent of the biller. 

17. The computer-readable medium of claim 14, wherein the billing information 
includes at least one of a customer profile or billing data associated with the customer. 

18. The computer-readable medium of claim 14, wherein the customer 
identification information includes one or more of name, address, phone number, e-mail 
address, social security number, date of birth, or account number. 

19. A computer-readable medium including instructions for performing a method, 
when executed by a processor, in a bill presentment and payment environment with a 
scheduled time to communicate billing information with a requesting IBPP system, for 
providing billing information, the method comprising comprising: 

receiving, from the requesting IBPP system, a request for information associated 
with a customer; 

retrieving the requested information; and 

forwarding the retrieved information to the requesting IBPP system at an 
unscheduled time. 

20. The computer-readable medium of claim 19, wherein the step of fonwarding 
the retrieved information comprises the steps of: 
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transfonning the retrieved information to a format accepted by the requesting 

IBPP system; and 

foHA^arding the transformed information to the requesting IBPP system. 

21. In a bill presentment and payment environment, a method of requesting 
information from a biller comprising; 

receiving customer registration information, including information sufficient to 
identify the customer; and 

providing the customer identification information to the biller as part of a request 
indicating enrollment in the bill presentment and payment system, 

wherein the request is provided to the biller in accordance with a bill data 
exchange protocol. 

22. In a bill presentment and payment environment, a method of providing billing 
data to a requesting IBPP system, the method comprising: 

receiving, from the requesting IBPP system, a request; 
retrieving the billing data based on the request; and 
providing the retrieved data to the requesting IBPP system, 
wherein the retrieved data is provided to the requesting IBPP system in 
accordance with a bill data exchange protocol. 

23. In a bill presentment and payment environment with a set of billers, a real- 
time bill presentment and payment method comprising: 
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receiving customer registration information, including Information sufficient to 
identify the customer; 

providing tlie customer identification information to one of tlie billers as part of a 
request indicating enrollment in the bill presentment and payment system; and 

permitting real-time access by the customer to billing information from the one of 
the billers. 

24. The method of claim 23, wherein permitting access by the customer to billing 
information comprises: 

transmitting a request to the one of the billers to access billing information; and 
receiving the billing information from the one of the billers. 

25. The method of claim 23, wherein the request is independent of the biller. 

26. The method of claim 23, wherein the billing information includes at least one 
of a customer profile or billing data associated with the customer. 

27. The method of claim 23, wherein the customer identification information 
includes one or more of name, address, phone number, e-mail address, social security 
number, date of birth, or account number. 

28. In a bill presentment and payment environment, a method for providing billing 
information to a requesting IBPP system in real-time, the method comprising: 



38 



Customer No. 22,852 
Application No.: 09/867,645 
Attorney Docket No. 06502.0342-00 

receiving, from the requesting IBPP system, a request for information associated 

witli a customer; 

retrieving the requested infomnation; and 

fonrt/arding the retrieved information to the requesting IBPP system in real-time. 

29. The method of claim 28, wherein the step of fonA^arding the retrieved 
information comprises the steps of: 

transforming the retrieved information to a fomnat accepted by the requesting 
IBPP system; and 

forwarding the transformed information to the requesting IBPP system. 
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IX. Evidence Appendix to Appeal Brief Under Rule 41.37(c)(1Hix) 

None. 
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X. Related Proceedings Appendix to Appeal Brief Under Rule 41.37(c)n)(x) 

None. 
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